rwsh is a shell for Unix-like systems.  

Documentation can be found in the docs directory.  As it is still very much of 
a proof-of-concept, there is no install or configure script.  

It is not intended to be compatible with existing shells, or even to keep their
basic semantics.  So please read at least the "introduction and 
philosophy" document before assuming that you know what a command will do. For
example, rm without arguments may delete files (personally, I use rm without
arguments more often than with them).

Several changes are coming shortly, which may easily break scripts designed for
this version of the shell, including the following.
     *  .while will respond to the .retest_condition exception by testing the
        condition, and ending the loop if it fails, but (unlike .continue)
        continuing with the following statement if it succeeds.
     *  Functions will be able to take more than one argfunction with string
        arguments being associated with each argfunction. For instance this
        will permit .scope to take several prototypes with an argfunction for
        each prototype, and will run the argfunction for which its arguments
        match the corresponding prototype.
     *  "Soons" will be replaced with "Earlies". The syntax will not
        (necessarily) change, but the meaning will. Rather than & meaning to
        evaluate the first time a containing statement is evaluated and && meaning
        to evaluate the second time a containing statement is evaluated, & will
        mean to evaluate at the beginning of the innermost block, and && will
        mean to evaluate at the beginning of the second most inner block. The
        result will be that wrapping a set of statements in a .scope or
        .collect_errors_* will not require changing the number of ampersands,
        and that the statement ".set FOO &FOO" will have the effect of
        restoring the value that $FOO had at the beginning of the block.
     *  Global variables will be replaced by a heirarchical set of scopes.
        Functions will be declared to place their variables as a child of the
        current scope (leaving none of the current variables immediately
        accessible and combining all of its variables into a single value for
        the current scope), or within the current scope (making all of the
        current variables available and making the function's variables part of
        the same map), or to attempt to do one of those two in the parent
        scope. If there is no parent scope then a .no_more_turtles exception
        will be thrown.
     *  Another use of the multiple argfunctions per statement will be the
        .select_all and .select_last builtins. They will run each of their
        argument functions in parallel, rotating between them when they input
        or output or request to cooperate with peers. .select_all will run
        until all argument functions complete, while .select_last will run
        until the last argument function specified completes, sending a sigpipe
        to any other argfunctions currently running.
     *  Variables and functions will likely share the same namespace, and using
        a function as if it was a variable will be equivalent to calling it
        without arguments. Running .set on such a function will call it with
        the arguments, but will throw an exception if it terminates without
        having the effect of setting the specified value (or throwing an
        exception of its own).
     *  Redirections will be handled by internal functions, so that the effect
	of >foo, or <bar<baz will be something that can change depending upon
	the configuration.
     *  When handling a set of arguments as a whole, rather than as a set of
	words, any excess space that was included when specifying them will be
	included.
     *  .for and .for_each_line will merge taking a separator and prototype(s)
        as an argument and receiving the list to be iterated through on stdin.
        Similarly, .scope and .reinterpret will take a separator with which to
        split stdin, and then apply the prototype (each of which will no longer
        need to be a single argument).
     *  .stepwise will step through the argument specifications as well as
        through the statements of a function, permitting one, for example, to
        identify the arguments that make use of a particular variable.
     *  Exception call stacks will include all of the arguments for each
        function at each level of the call stack rather than just the
        executable names.
     *  .run_logic will be replaced by a system that treats .shell as a service
        which includes the request for user input, and which restarts after
        each command. As with .function_not_found, a missing implementation
        will be replaced with a simple implementation.
     *  a "/" will be used to define a heirarchy amongst executables and
	variables. $foo/bar cannot be defined without defining $foo, and it
	will return the portion of $foo that immediately follows "bar=".
	Running "foo bar" will run the function that was named "foo/bar".
     *  Currently, $foo$3 returns the third word of the variable foo. This will
        be replaced with a system of filters, which can be used to select
        members of a structure without being limited to whitespace-delimited
        structures, as well as being able to optionally handle variables that
        are not defined.
     *  There will be "default redirections", so that interactive commands will
	not necessarily have either their input or output connected to the
	terminal. The builtin .is_default_input should be used to determine
	whether a command is receiving its input effectively from the user, and
	.is_default_output should be used to determine whether output is
	intended to be printed on the terminal.
Other large changes are likely. To illustrate, before version 0.3, ERRNO was a
special variable, that would prevent the execution of control flow statements
such as .if and .while. Experience working with this setup convinced me that
the problem I was aiming at was worth taking on, but that my first solution was
actually an enormous pain most of the times it came up. I could very easily
come to the same conclusion about some other feature that I have already
implemented or will soon implement.

